Technology companies are developing more complex products than ever before. Fortunately for technology businesses today, newly emerging product development tools allow organizations to bring their complex products to market faster than years prior. Specifically, the aviation and automotive industries rely on advanced simulation to rollout quality products in less time.
Software-in-the-loop (SWIL) and hardware-in-the-loop (HWIL) processes are two popular simulation solutions used by unmanned aerial vehicle (UAV) manufactures.
Software-in-the-loop
SWIL is a type of software testing that detects bugs or regressions in systems. When testing autopilots using SWIL simulation, the autopilot software is recompiled to run on a typical desktop computer and then linked to a six-degrees-of-freedom simulator (6-DOF). This simulator sends and receives data to the vehicle being tested. Specifically, the software converts servo outputs into control inputs to the 6-DOF. Likewise, the software also converts 6-DOF outputs into simulated autopilot sensors inputs (e.g. GPS, pressure altitude, pressure airspeed, acceleration, and gyro rates).
Advantages of SWIL
SWIL simulators are easy to develop. The programming required to convert servo outputs from the autopilot software into inputs to the 6-DOF is simple to generate. Additionally, converting state output of the simulation (e.g. position, altitude, acceleration and angular rates) into appropriately formatted sensor information (e.g. pressure altitude, pressure airspeed, and GPS position) is not complex.
Furthermore, SWIL systems do not require specialized hardware to test the majority of a project's code base, making them simpler and less expensive than other alternatives. With minimal components needed and low costs, SWIL is a popular training aid and testing alternative for several autopilot configurations.
In addition to benefits, such as simple programming and minimal spending, manufacturers in the UAV, aerospace and automotive industries also overcome the obstacle of time with SWIL. For example, design teams reduce some types of testing from months to hours, since an hour flight can be simulated within a few seconds. Faster-than-real-time testing is extremely useful when testing software against a large number of possible inputs, as well as when running optimizations on software. For example, regression tests can be run nightly to test its autopilot software. These tests would take months in real time to simulate, as opposed to hours with a SWIL simulator.
Disadvantages of SWIL
Although a SWIL can test significant portions of an autopilot's software, this type of simulation does not complete a UAV engineer's toolbox. First, most SWILs run off of a PC-based workstation, while the real autopilot runs off of an embedded processor. The discrepancies between these two types of processors provide a testing environment that does not adequately mimic real flight.
For example, autopilot software is typically compiled with a different tool chain than what the SWIL relies on. Therefore, errors introduced by the autopilot's tool chain will not become evident. Moreover, design teams cannot test inputs and outputs (I/O) or software specific to target processors. Nor can they control real hardware, such as servos, camera systems, speed controllers and radio modems.
Furthermore, SWIL's timing differs from the real autopilot's timing. Typically, SWILs run at least ten times faster than real autopilots. This is because SWILs run on computers relying on clock speeds of several gigahertzes, while autopilots depend on microprocessors running at a few hundred megahertz. Another issue to consider is code that interacts with I/O devices (e.g. analog to digital converters, serial channels, and servo output channels) does not carry over to a SWIL arrangement. These disparities fail to simulate close to all possible errors. Therefore, systems that rely on SWIL alone cannot be used to construct an iron bird (as discussed later).
Hardware-in-the-Loop (HWIL)
Both HWIL and SWIL simulation rely on a 6DOF simulator to simulate the UAV in flight; however, the arrangement varies slightly. SWILs run both the autopilot software and the 6DOF on one computer. Conversely, HWIL's run the 6DOF on a typical desktop computer, while the autopilot software runs on real autopilot hardware. Then, the autopilot's outputs (servo signals and other control signals) are sent to the 6DOF and the simulator output is returned to the autopilot.
The aviation industry has been employing HWIL simulation for over twenty years to test aircraft software before they leave the ground. HWIL simulation allows UAV manufacturers to run systems on the actual hardware and processors that the UAV is deployed on during real flight. Equally essential, the system uses the true compiled code that the UAV relies on during real flight. This true-to-life simulation allows design teams to test systems with outputs that depend on present and past inputs, as well as systems with multiple outputs functioning on several inputs.
UAV autopilot manufacturers use HWIL simulators to ensure that autopilot software works correctly. UAV manufacturers incorporate HWIL to assist them in validating that their entire system works correctly.
Building Iron Birds with HWIL
Competent UAV manufacturers employ HWILs to build iron birds, a complete set of aircraft hardware. Iron birds include installed actuators, motors, cameras, and communication equipment. In ideal circumstances, the iron bird's component wiring is identical to the wiring of the real system. Although an iron bird is arranged on a table instead of installed within a vehicle, all flight components are included.
UAV manufacturers rely on iron birds to:                a) Ensure all systems and subsystems work together prior to first flight.        b) Access instrument systems and subsystems. Since systems remain on the ground, engineers maintain better access to systems and subsystems.        c) Facilitate tests that are either impractical or too dangerous to perform during flight, such as stressing systems beyond design limits and checking thermal performance.        d) Implement accelerated life testing, servo movement, and current consumption, prior to first flight.        e) Validate extended flights. HWIL can test flights that last months. (True HWIL, as will be discussed later, is necessary for this test.)        
A HWIL simulator is not mandatory when building an iron bird; however, UAV design teams greatly increase the range of tests they can perform with the addition of a HWIL autopilot simulator. Without employing a HWIL simulator, design teams can perform useful tests, such as overall current consumption, actuators at or beyond their rated load, component vibration toleration, and component under elevated temperatures. Without a HWIL incorporated into the iron bird, all tests that require simulated UAV flight are beyond reach. The design team cannot validate the entire UAV under typical flight conditions unless a HWIL is used in the iron bird. Since a key component of any unmanned system is the autopilot, it is important to incorporate the autopilot into the simulation before actual flight. The preferred method is to employ a hardware-in-the-loop simulator along with the autopilot.
QuasiHWIL Versus THWIL
HWIL simulation can be broken down into two types: quasi-hardware-in-the-loop and true-hardware-in-the-loop. In both types, autopilot software runs on the actual autopilot, however, the two simulators differ, as will be explained and as shown in FIG. 1.
Quasi-Hardware-in-the-Loop (qHWIL): In a qHWIL system, autopilot software runs on the actual autopilot, which provides more comprehensive and more realistic testing than SWIL simulators. In a qHWIL arrangement, the autopilot and simulator communicate either via a serial port, CAN bus, Ethernet, or other communication mechanism. However, when servo signals and sensor data are exchanged in this way, code executed by the autopilot is not identical to what the autopilot executes in flight. Before the servo values are output to the communication mechanism 106, control loops or PID are calculated 102 and servo mixing is performed 104. The simulator will read the servo values from the communication mechanism 106, then calculate simulated sensor values based on the servo values and a physical model. The simulator will output these sensor values via the serial port or CAN bus. The autopilot will read the sensor values from the communication mechanism 108, then calibrate the sensor values it receives 110 and use the calibrated sensors for the next iteration of the control loops. This is in contrast to a real autopilot where the servo values are output 112 to PWM hardware on a processor and the sensor values are read 114 directly from ADC converters or direct from the sensors.
Also important to note, during qHWIL simulation, the flight must run in real time and include an autopilot. On the up side, design teams can control real hardware with qHWIL and therefore implement a simulated iron bird.
True-Hardware-in-the-Loop (THWIL): As with qHWIL, in THWIL arrangements, autopilot software runs on the actual autopilot and simulators run on PCs. The autopilot and simulator communicate electrically using the same mechanisms that the autopilot uses to communicate with the sensors and servos in real flight. Before the servo values are output to the PWM hardware 112, control loops or PID are calculated 102 and servo mixing is performed 104. Simulators read servo outputs from the autopilot via the PWM hardware and generate correct electrical signals to simulate the autopilot sensors. The autopilot reads the sensor values 114 directly from ADC converters or direct from the sensors. The autopilot will calibrate the sensor values it receives 110 and use the calibrated sensors for the next iteration of the control loops.
Although, qHWIL offers more fidelity than SWIL, qHWIL simulation introduces inaccuracies due to data coming into UAVs through serial ports and CAN buses instead of directly from sensors. THWIL offers the truest-to-life simulation for UAVs available on the market today. The THWIL electrically simulates all analog sensor outputs using analog-to-digital converters, signal conditioning and PWM interface boards. All sensors are removed from the autopilot.
There are no delays introduced by transmitting sensor values, since the simulator generates the actual sensor signals. The THWIL allows for adjusting flight parameters, as well as checking integrity and functioning of on-board equipment and payloads. THWIL allows the replication of UAV flight conditions, which provides design teams with superior on-the-ground validation of autopilot setup and integration.
In the THWIL of Micropilot, trueHWIL™, MathWork's MATLAB is used as a simulation and programming environment. Models built using Simulink and MATLAB are compiled and sent to the xPC Target computer with installed I/O hardware. This acquisition hardware is connected to the autopilot and reads its outputs and stimulates its inputs. Connection can also be made to other UAV hardware components to provide extended functionality of the simulator.
Please note, THWIL simulators require a sensorless autopilot or an autopilot in which the sensors have been disabled so that the pins that the sensors would use can be used for input. In addition, this simulator can control real hardware, and therefore can be used to implement an iron bird. Although iron birds can be based on quasiHWIL, those built using THWIL are more effective.
In THWIL, the sensors (gyros, accelerometers, airspeed pressure sensors, altitude pressure sensors) are stripped off of an autopilot and the sensor inputs to the autopilot are electrically simulated. Using a number of PWM (Pulse Width Modulation) input channels or an analog voltage signal, the simulator reads servo positions from the autopilot. The simulator then simulates the vehicle's reaction to those control inputs and calculates the appropriate sensor outputs and translates them into the appropriate analog voltages (the same voltage the sensor would generate). The autopilot reads these voltages as if they come from a real sensor. The advantage of this type of simulation is the autopilot executes its code as if it flying the drone—it has no idea it is flying a simulator so the code paths the processor would take are the same as without a simulator.
Many autopilot implementations are now switching to digital sensors that communicate with the autopilot over an SPI (Serial Peripheral Interface). The above described simulation of sensors works well with analog sensors but does not work with digital sensors. These digital sensors have analog to digital converters built in and therefore the simulator has no access to the analog signal. Simulating the digital outputs is much more difficult.
Digital sensors communicate with a microcontroller over some form of clocked serial bus—either SPI (Serial Peripheral Interface) or I2C (Inter-integrated Circuit). Typically, these sensors have a number of registers that contain sensor data and status information and have a two word communication process. The first word will be a command from the microcontroller (or master) to the sensor (or slave) and the second word will be data from the sensor to the microcontroller. Typically the microcontroller will start the process using a chip select signal in the case of SPI (in I2C, the address is built into the command so no chip select is necessary) followed by transmitting a command word to the sensor. The command word will be a fixed number of bits. The number of bits in the command word depends upon the sensor. The command word will contain a number of bits that specify which register within the sensor the microcontroller wishes to read. Examples of types that can be included in the command word are read/write and register number. Typically, between two and four bits will be used to select the register and the position of these bits within the command word varies with each sensor. Immediately after receiving the command word, the sensor will respond with the data word. The length of the data word varies with each sensor and the contents depend upon the register address specified in the first word.
These sensors are implemented directly in hardware and have no microcontroller. As such, the response time between receiving the last bit of the command word and outputting the first bit of the data word is very short. Typically, the response time is a single bit time. As clock rates for these devices can go into the hundreds of kilohertz or megahertz it is not possible to emulate one of these sensors using software on a microcontroller. The time is too short for microcontroller clock rates.